Embedded objects are increasingly used on webpages to enhance the interface capabilities, functionalities, and interactive control provided to users. These technologies allow users to interact with and within the webpage and provide developers with a rich set of tools to dynamically update the webpage interface. Embedded objects, such as plug-ins, are often used to obtain information from a user or to visually present information in an interactive manner. Examples of use include animation in a web browser and motion graphics—many embedded objects present dynamic visual images that may be manipulated by the user.
The term embedded objects includes, but is not limited to, internet browser plug-ins such as Adobe Flash, Microsoft Silverlight, ActiveX controls, Java applets, and 3DMLW. Further, there may be various types of embedded objects integrated throughout a single webpage to enhance the user's experience. The term “webpage” refers to any document or resource of information that is suitable for the World Wide Web and can be accessed through a web browser and displayed on a computer screen. This information is usually presented in HTML or XHTML formats. The term “integrated webpage” refers to a webpage containing at least one embedded object. Additionally, the term “native” refers to any object in a format inherently supported by a web browser.
Embedded objects are often implemented as plug-ins in a webpage and are able to operate independent of a web server. Often data updates and interface presentation modifications occur without requiring webpage regeneration and without web server interaction. In this case, the user interaction with the embedded object remains internal to the embedded object without being recognized by the webpage server and the state of the embedded object does not have to be maintained on the server.
Users often need to capture the visual representation of an integrated webpage including the changes and modifications in the image representation of the embedded object that occur as a result of the user's input. This may occur in the context of storing, printing, capturing or converting the webpage as it is presented to the user. However, because user interaction with the embedded object is conducted internally within the embedded object and not recognized by the webpage server, users often cannot capture the current visual presentation of the integrated webpage. For example, when a user wishes to print an integrated webpage, the web browser converts the embedded objects to native formats. The browser essentially performs a screen capture of the embedded object and only the currently visible portion of the object can be captured. This capture also contains unwanted artifacts such as scroll bars required for interactive use. The capture is based on the display size so it is often too large for printing and results in truncation of portions of the image.
Further, in many contexts it is also required that users be able to print, capture, or save an entire webpage as it is coded regardless of the actual visual presentation on the user's monitor. It is also valuable for users to be able to capture the visual representation of a webpage without having to instantiate that webpage in a web browser. In both of these cases, the user may wish to capture, print, or store the integrated webpage as it has been coded and reflecting the changes to the embedded object regardless of the webpage's presentation or whether the webpage has been loaded into a web browser at all.
Existing solutions for capturing the visual representation of an integrated webpage include using a screen capture or extending the webpage markup language to include the embedded object. Yet, neither of these solutions provides an efficient and reusable method of capturing the current visual representation of an integrated webpage as it appears to the user or as it has been coded.
The screen capture method utilizes the screen capture function on a computer to take a picture of the visible items displayed on the computer monitor and typically saves the image as a bitmap image. While this method does capture the current image representation of the integrated webpage, it also captures the entire visible display making it necessary for the user to alter or crop the bitmap image to obtain an accurate representation of the webpage. Each screen capture image requires a unique alteration in order to capture the desired image—the integrated webpage as presented to the user. And when the web page is larger than the screen, multiple images must be captured and edited together. This labor-intensive process, requiring multiple steps and actions by the user, often results in a poor quality and inaccurate bitmap image of the webpage and is difficult to automate. Also, this method requires the web server to regenerate the integrated webpage often resulting in an inaccurate image replacement.
Another solution, extending the markup language (most often HTML or XML) to include the embedded object, attempts to replace the use of embedded objects with new objects that are native to the selected markup language. For example, HTML 5 introduces the canvas object as an alternative for Flash and Silverlight. But extending a markup language requires comprehensive programmatic change and web browser upgrades—without which the embedded objects are not supported. Further, when utilizing this approach to print an integrated webpage, the webpage may regenerate and the HTML converted embedded object is reloaded and printed in its default state.
Another option is to create “printer-friendly” alternative pages. In this case, the server builds “printer-friendly” pages using native objects instead of embedded objects. In the context of HTML or XML, native may refer to such image representations as, for example, JPEGs, PNGs, and GIFs. This approach requires the web server to know the state of the client presentation to produce a native image instead of the embedded object. There are a number of options for transmitting the embedded object's state; for example, some solutions utilize features such as Fat URLS, hidden fields, and cookies for maintaining state. However, this approach requires the web server to create two implementations to render graphics; one for the page with embedded objects and the other for the page with native objects.